Czynności i przepływy procesu

Środowiskiem pracy projektanta procesu jest produkt docuRob®WorkFlow proces modeler pozwalający na konstrukcje graficznych modeli procesów zgodnych z wytycznymi standardu OMG BPMN v. 2.02. Zgodnie z przyjętą metodyką projektowania można wykorzystywać narzędzie w poszczególnych fazach cyklu życiowego projektu od pojęciowego modelu procesu do jego wykonywalnej definicji.

Wykonywalna definicja procesu jest udostępniana w repozytorium procesów utrzymywanego w ramach narzędzia zintegrowanego z platformą wykonawczą produktu docuRob®WorkFlow. W ramach repozytorium definicji procesów zapewnione zastało elastyczne zarządzanie umożliwiające wersjonowanie definicji oraz kontrolowane wprowadzanie ich do eksploatacji. Platforma pozwala na równoczesne przetwarzanie procesów inicjowanych na podstawie różnych wersji ich definicji.

W dalszych sekcjach rozdziału omawiamy poszczególne klasy obiektów modelu procesu (ang. flow object) wykorzystywanych do tworzenia kolejnych poziomów modelu procesu.

Opis procesu

Definicja procesu (ang. process definition) jest kompletną reprezentacją procesu umożliwiającą jego wykonanie przez system zarządzania procesami. Definicja procesu dotyczy różnorodnych aspektów procesu, w szczególności: przepływu sterowania, przepływu danych, przypisania wykonawców oraz wywołania aplikacji w ramach czynności.

Modyfikacja definicji procesu powoduje utworzenie nowej wersji definicji. W danym momencie może istnieć (i być wykonywanych) wiele wersji tego samego procesu, ale tylko jedna z nich jest najbardziej aktualna, dostępna i będzie wykonywana dla wszystkich nowo uruchamianych procesów. Definicja procesu może być też częścią innego, bardziej złożonego procesu.

Proces (jego definicja) może wymagać parametrów wejściowych oraz produkować rezultaty wykonania w postaci parametrów wyjściowych. Zakładki ekranu definicji procesu prezentuje Rysunek 1.

Nazwa procesu stanowi unikalny identyfikator definicji procesu w ramach danej instalacji docuRob®WorkFlow przy czym kolejne wersje definicji są identyfikowanych liczbami całkowitymi począwszy od 1.

Priorytet wyznacza poziom preferencji dla wszystkich instancji procesów uruchamianych na poziomie tej definicji. Priorytet może być określony zarówno na poziomie procesu jak i na poziomie definicji czynności. Domyślną wartością wskaźnika jest liczba 100 a maksymalna jego wartość to 2147483647. Definicja procesu wywoływana jako podproces może dziedziczyć priorytet odpowiadającej jej czynności złożonej lub zachować własny.

Data dostępności informuje o dacie udostępnienia procesu i określa początek okresu jego wykorzystania, natomiast data ważności określa czas do którego nowe instancji procesu mogą być tworzone na podstawie tej definicji.

Informacja o realizacji procesu określa maksymalny czas przetwarzania instancji procesu oraz wskazuje osobę, która otrzymuje komunikat o przekroczeniu tego ograniczenia. Czas wykonania instancji procesu jest wyznaczany jako liczba dni i godzin od momentu uruchomienia instancji procesu. Przekroczenie zdefiniowanego czasu powoduje, że cała instancja procesu jest opóźniona. Dodatkowo możliwe jest też zdefiniowanie reguły wyboru pracowników, którzy powinni zostać powiadomieni w przypadku zaistniałego opóźnienia. Reguła ta ma te same ograniczenia co reguły wyboru wykonawców w czynnościach.

Zakładka Przypomnienie pozwala na wyznaczenie ram czasowych ostrzeżenia, również z dokładnością dni i godzin, o obowiązku rozpoczęcia obsługi zadania. Potencjalni wykonawcy zadania są wybierani w oparciu o wyrażenie przydziału wykonawcy(ów) (ang. work participant assignment) [WPA]) BPQL. Definiowane na poziomie procesu ograniczenie podjęcia zadania dotyczy wszystkich zadań wykonywanych przez uczestników procesu.

Właściciel instancji (ang. process owner) identyfikuje osobę odpowiedzialną za jego utrzymanie i eksploatację oraz najczęściej za wszystkie jego aspekty związane ze wspieraną przez niego działalności biznesową. Osoby występujące w tej roli zwyczajowo otrzymują wszystkie standardowe komunikaty dotyczące przekroczenia ograniczeń.

Alternatywny wykonawca, również wyznaczany przez wyrażenie BPQL, przejmuje wykonania zadania przekraczające określone ograniczenia czasu wykonania wyrażone jako okres czasowy poprzedzający wyznaczony termin zakończenia zadania.

Parametry zdarzeń są wykorzystywane w zdarzeniach obsługujących sytuacje wyjątkowe przez reguły BPQL. Dzięki temu można elastycznie przypisywać wartości poszczególnym parametrom wywoływanych aplikacji. Reguły BPQL użyte do przypisań mają jedne ograniczenie: muszą zwracać wartość o typie zgodnym z typem argumentu wywoływanej aplikacji

Ograniczenia czasowe dotyczące otwierania zadań wyznaczają maksymalny czas od utworzenia zadania na liście lub listach potencjalnych wykonawców do rozpoczęcia realizacji zadania. Podobnie jak w poprzednich przypadkach o przekroczeniu tego ograniczenia zostanie powiadomiona wyznaczona osoba.

Czynności

Czynność (ang. activity) jest pracą, która określa pojedynczy krok w ramach procesu. Czynność może być atomowa, złożona lub sterująca. czynność atomowa jest definiowana jako zadanie, czynność złożona jako podproces a czynność sterująca jako bramka.

Kolejność przepływu pracy pomiędzy czynnościami jest zdefiniowane przez rodzaj i warunki wyboru odpowiedniego przejścia. Każda czynność może mieć czynności ją poprzedzające i czynności następujące bezpośrednio po niej.

W ramach definicji czynności możemy wyznaczyć ich rodzaj (ang. kind) wstawiając w dolnej linii graficznego symbolu czynności odpowiednie wskaźniki rodzaju czynności. Reguły ich współwystępowania w definicji czynności oraz znaczenie określają odpowiednio Tabela 1 i Tabela 2.

znacznik	Współwystępujące znaczniki
	Pętla	Pętla sekwencyjna	Pętla równoległa	Ad hoc	Kompensacja
Pętla	X				T
Pętla sekwencyjna		X			T
Pętla równoległa			X		T
Ad hoc	T	T	T	X	T
Kompensacja	T	T	T	T	X

Tabela 1. Reguły użycia Wskaźników rodzaju czynności w metadanych

Rysunek 1. Zakładki definicji procesu

Grupy metadanych czynności, wspólne dla potomnych obiektów modelu i udostępniane w ramach hierarchii dziedziczenia, są prezentowane w tej sekcji. Pozostałe elementy metadanych są omawiane odpowiednio w sekcjach dotyczących zadania i podprocesu. Dodatkowo poświęcono osobną sekcję na opis podprocesu Ad hoc ze względu na jego specyficznych charakter.

Informacje ogólne zawierają takie elementy jak nazwa czynności i numer czynności w ramach tworzonego modelu procesu. Dla czynności Użytkownik, Usługa, Skrypt i Podproces są definiowane wskaźniki rodzaju czynności które zawiera Tabela 2. Pole Opis pozwala na tworzenie dokumentacji czynności, która opcjonalnie może być udostępniana również użytkownikom instancji procesu wykonujących to zadanie.

Wskaźnik	Nazwa	Opis
	Pętla	Czynność jest wykonywana w pętli do momentu zmiany wartości zmiennej kontrolującej zakończenie pętli na logiczną wartość ‘true’. Zmienna logiczna jest inicjowana wartością ‘false’ w trakcie instancjacji czynności. Warunek kończenia jest definiowany jako wyrażenie warunkowe BPQL umieszczone w zakładce postakcja.
	Pętla sekwencyjna	Deklaracja pętla sekwencyjna (ang*.* Multi-instance) powoduje kolejne wykonanie przetwarzanych instancji czynności. Każda instancja jest wykonywana osobno dla każdego wykonawcy znajdującego się w zbiorze wynikowym wyrażenia BPQL wyznaczającego listę wykonawców.
	Pętla równoległa	Deklaracja pętla równoległa (ang. parallel multi-instance) powoduje uruchomienie współbieżne przetwarzanych instancji czynności. Instancja jest wykonywana osobno dla każdego wykonawcy znajdującego się w zbiorze wynikowym wyrażenia BPQL wyznaczającego listę wykonawców.
	Ad hoc	Wskaźnik może występować zarówno w przypadku definicji zadania jak i podprocesu. Znacznik Ad hoc użyty w symbolu podprocesu oznacza, że wszystkie czynności tego podprocesu, które nie są ograniczone przepływem mogą być wykonywane w oparciu o dyscyplinę Ad hoc. Oznacza to, że wszystkie takie zadania typu Użytkownik występujące w ramach tego podprocesu mogą być wykonywane wielokrotnie przez wszystkich użytkowników wyznaczonych dla nich wyrażeniem BPQL. Instancje zadania lub podprocesu Ad hoc są aktywizowane razem z zawierającą ją instancją procesu/podprocesu. Przetwarzanie instancji zadania Ad hoc jest kończone poprzez określony dla niego warunek zakończenia zadania. Przetwarzanie instancji podprocesu Ad hoc jest kończone gdy zachodzą wspólnie następujące warunki: Wszystkie instancji zadań procesu są zakończone. Warunek zakończenia instancji Ad hoc jest prawdziwy, tj. wyrażenie warunkowe BPQL ma wartość ‘true’.
	Kompensacja	Wskaźnik kompensacja oznacza czynność, która odwraca skutki powiązanych z nią czynności, to jest zadania lub podprocesu. Powiązanie kompensowanej czynności jest realizowana poprzez odpowiednie zdarzenie przechwytujące „kompensacja” powiązane przez związek (ang. Association) z czynnością kompensującą. Warunkiem wykonania kompensacji jest pozytywne zakończenie odwracanej czynności. Jeżeli taki warunek nie zachodzi dla wskazanej czynności to kompensacja nie jest wykonywana.

Tabela 2. Znaczniki wyznaczające rodzaj czynności

W dolnym prawym roku formatki udostępniono dwa klawisze funkcyjne pozwalające na:

• Zatwierdzanie definicji czynności zgodnie z wnikliwością kontroli określoną w Opcjach narzędzia.
• Anuluj powoduje zakończenie definicji czynności

Rysunek 2. Metadane typu obiektu czynność

W ramach zakładek Wykonawca, Post-akcja oraz Pre-akcja występuje pomocnik wyrażeń BPQL, dostępny przez usługę Wstaw, obsługujący wybór odpowiednich elementów wyrażeń z udostępnionych słowników (patrz Rysunek 3).

Rysunek 3. Pomocnik wyrażeń BPQL

Wybór ścieżki wykonania procesu jest oparty o definicje konfiguracji przepływów wchodzących i wychodzących z czynności lub bramek. Instancjacja elementów grafu procesu polega na obsłudze znaczników (ang. token) przepływających między nimi lub w przypadku zdarzeń na generowaniu lub otrzymywanie wyzwalaczy zdarzeń (ang. trigger). Pojęcie znacznika zostało wprowadzone jako intuicyjna ilustracja mechanizmu przekazywania sterowania pomiędzy elementami grafu procesu.

Definiowanie w ramach metadanych czynności zależności logicznych pomiędzy wchodzącymi przepływami pozwala na przyjęcie pożądanej dyscypliny instancjacji danego elementu grafu procesu a w przypadku wychodzących przepływów na wybór dalszej ścieżki przepływu znaczników. Definicję złączenia i rozpływu sterowania przestawia Rysunek 4.

Złączenie sterowania wejściami wielu wchodzących przepływów, lub inaczej obsługa wielu znaczników wchodzących do czynności, zależy od wskazanego operatora powodując dla:

• operatora AND instancjację czynności po wejściu znaczników przez wszystkie wchodzące przepływy
• operatora OR instancjację czynności po wejściu znaczników przez wszystkie wchodzące przepływy spełniające zdefiniowane dla nich wyrażenie warunkowe
• operatora XOR instancjację czynności po otrzymania pierwszego znacznika przez jakikolwiek z wchodzących przepływów.

Rozpływ sterowania wyjściami wielu wychodzących przepływów, lub inaczej obsługa wielu znaczników wychodzących z czynności, zależy od wskazanego operatora powodując dla:

• operatora AND wysłanie znaczników przez wszystkie wychodzące przepływy
• operatora OR wysłanie znaczników przez wszystkie wychodzące przepływy spełniające zdefiniowane dla nich wyrażenie warunkowe
• operatora XOR wysłanie znaczników przez pierwszy wychodzący przepływ spełniający zdefiniowane dla niego wyrażenie warunkowe lub nie ograniczone żadnym warunkiem

Rysunek 4. Parametry złączenia i rozpływu sterowania

Alternatywną techniką sterowania wyborem ścieżki procesu są bramki, które, poza większą elastycznością wyboru ścieżki procesu, stanowią istotne elementy pojęciowego modelu procesu. Sterowanie przepływem wykorzystujące bramki opisano szczegółowo w dalszych częściach dokumentacji. Bramki ze względu na ich widoczność w grafie procesu/podprocesu są preferowaną techniką definiowania rozgałęzień przynajmniej na poziomie pojęciowego modelu procesu.

Niezależnie od typu i rodzaju czynności wprowadzono możliwość wykonania skryptu BPQL lub zewnętrznej Aplikacji zarówno przed jej wykonaniem (Pre-akcja) jak i po jej wykonaniu (Post-akcja). Interfejs dla wprowadzenia skryptu BPQL przedstawiają odpowiednio Rysunek 5 i Rysunek 6.

Rysunek 5. Definicja Pre-akcji czynności

Akcje pozwalają na:

• wykonywanie dodatkowych działań na parametrach wejściowych i wyjściowych procesu, zmiennych globalnych lub parametrach wywoływanej w czynności aplikacji (np. ustawianie statusu, dodawanie wartości do licznika pętli, itp.)

• wywoływanie dodatkowych aplikacji przed rozpoczęciem i przy zakończeniu czynności.

  Akcje są wykonywane:

• w momencie przypisania czynności do danego wykonawcy. Akcja ta jest nazywana preakcją.

• w momencie kończenia wykonywania czynności (nie dotyczy przerywania czynności). Akcja ta jest nazywana postakcją.

Akcja jest reprezentowana jako wyrażenie BPQL lub jako wołana aplikacja. W przypadku reguły BPQL, w odróżnieniu od przypisania wykonawcy czy warunku przejść, nie ma ograniczeń na wartość zwracaną przez regułę BPQL wykonywaną w akcji.

Akcje wykorzystuje się najczęściej do odpowiedniego przygotowania parametrów wejściowych i wyjściowych aplikacji wywoływanej w czynności. Innym zastosowaniem akcji jest wykorzystanie jej do ustawiania wartości wskaźników procesu wyrażonych poprzez zmienne globalne.

Aby zdefiniować Preakcję, należy:

• w panelu listy procesów kliknąć na dany proces,
• przejść w prawym panelu na zakładkę 'Model' procesu. Odnaleźć właściwą czynność i kliknąć dwukrotnie. Na ekranie pojawi się okno dialogowe właściwości czynności,
• kliknąć na węźle Pre akcja.
• Wybrać właściwy Typ akcji.
• Jeżeli wybranym typem jest BPQL – należy zdefiniować właściwa regułę BPQL. Jeżeli została wybrana aplikacja, to należy podać specyfikację jej wywołania tak jak przy definiowaniu aplikacji.

Dla skryptu Pre-Akcji wprowadzono dodatkowo możliwość wykonania go w całości lub częściowo przed instancjacją czynności oznaczając go jako blok @beforePreAction.

Kod zawarty w tym bloku w odróżnieniu od reszty Pre-akcji, zostanie wykonany już podczas tworzenia czynności. W sytuacji gdy zdefiniowanych jest n wykonawców danej czynności, blok @beforePreAction wykonany zostanie n razy podczas tworzenia czynności (tworzonych jest n instancji czynności), natomiast pozostała część pre-akcji wykona się raz, bezpośrednio przed wykonaniem czynności.

Postakcję definiuje się analogicznie wybierając węzeł Post akcja.

Rysunek 6. Definicja Post-akcji czynności

W przypadku złożonych procesów o dużej zmienności typów obsługiwanych przypadków użycia ważnym elementem projektu otoczenie procesu jest wyznaczenie odpowiednich zasobów ludzkich dla zadań typu Użytkownik. Jednym z elementów parametryzacji Analitycznego symulatora wykorzystywanego w tym celu jest określenie parametrów wydajnościowych każdej czynności.

Rysunek 7 prezentuje interfejs opisu takich parametrów wydajnościowych czynności jak liczba potencjalnych wykonawców i średni czas realizacji zadania. Opcjonalnie można również podać średni koszty wykonania zadania.

Opis algorytmu Analitycznego symulatora oraz przykład jego zastosowania w projektowaniu oraz zarządzaniu procesem jest dostępny w dalszej części dotyczącej monitorowania i analizy działania procesów.

Rysunek 7. Parametry analitycznego symulatora dla czynności

Zadanie

Zadanie jest niepodzielnym elementem modelu w odróżnieniu od podprocesu, który może zawierać dowolnie złożony model obejmujący wiele elementów. Typy zadań wraz z ich symbolami graficznymi oraz opisem działania prezentuje Tabela 3.

Symbol	Nazwa	Opis
	Komunikat	Zdanie automatyczne wysyła komunikat zawierający metadane oraz treść komunikatu poprzez wywołaną aplikację służącą do komunikacji (poczta elektroniczna, komunikator elektroniczny, SMS). Parametry umieszczone w kontenerze procesu są przekazywane Aplikacji komunikacyjnej zgodnie z wymaganiami przyjętymi dla zadania typu Usługa.
	Odbiór	Zadanie po otrzymaniu znacznika nasłuchuje na otrzymanie wyzwalacza rzuconego przez odpowiadające mu zadanie rzucające Komunikat. Obsługa komunikatu wymaga wywołania odpowiedniej aplikacji kompatybilnej z aplikacją wykorzystaną w zadaniu rzucającym. W przypadku bramki sterowanej zdarzeniem zadanie występuje jako jedno ze zdarzeń wskazujących przepływ wychodzący bramki.
	Użytkownik	Wykonawcą zadania jest uprawniony Użytkownik, który otrzymał informacje o nowym zadaniu na swojej liście zadań. Interfejs wraz z odpowiednimi usługami jest dostarczany przez aplikację wywoływaną przez silnik workflow. Silnik docuRob®WorkFlow standardowo obsługuję interface użytkownika poprzez zintegrowany moduł formularzy elektronicznych. Przydział zadania do jednego lub wielu użytkowników jest sterowany przez skrypt BPQL wykorzystujący takie cechy potencjalnych wykonawców jak uprawnienia, kompetencje oraz miejsce i funkcja w strukturze organizacyjnej czy rola w procesie biznesowym.
	Ręczna	Zadanie jest udostępniane przez listę zadań odpowiedniemu użytkownikowi lub użytkownikom lecz nie jest w żaden sposób zarządzanie przez silnik workflow za wyjątkiem oznaczenia śledzonych punktów czasowych w tym czasu rozpoczęcia i zakończenia
	Reguła biznesowa	Zadanie wykonywane automatycznie w oparciu o wyrażenia warunkowe BPQL. Wyrażenia warunkowe zawierają zmienne globalne procesu, zmienne lokalne skryptu oraz dane zewnętrznych baz danych i/lub plików XML. Wynikiem działania jest ustawienie wartości odpowiednich zmiennych globalnych procesu.
	Usługa	Zadanie jest wykonywane przez dostępną Usługę sieciową lub przez Aplikację wywołaną bezpośrednio przez silnik workflow. Wołane aplikacje są odpowiedzialne za obsługę interface użytkownika i mogą być implementowane w dowolnym języku programowania.
	Skrypt	Zadania jest wykonywane przez skrypt BPQL działający w oparciu o dane kontenera procesu, zmienne ontologii procesu, oraz o zewnętrzne źródła danych.

Tabela 3. Typy obiektu zadanie.

Przypisanie aplikacji (ang. application call specification**) definiuje sposób wywołania danej aplikacji w ramach** zadania**. Dotyczy to również określenia reguł mapowania parametrów wejściowych i wyjściowych** podprocesu**.**

Rysunek 8. Definicja parametrów Aplikacji obsługującej obiekt zadanie

Mapowanie parametrów Aplikacji (Tabela 4) określa jak:

• przypisać wartość parametrom wejściowym aplikacji wykonywanych w ramach czynności,
• przypisać zmienną globalną, do której zostaną przekazane rezultaty wykonania aplikacji czynności.

Do definiowania mapowań wykorzystywane są reguły BPQL. Atrybuty mapowań parametrów są opisane w Tabela 4.

Definicja Aplikacji jest wymagana dla takich typów zadań jak Użytkownik i Usługa oraz opcjonalne dla typu czynności Wysłania i Odbioru oraz Reguły biznesowej. W pierwszym przepadku istnieje możliwość wykorzystania zewnętrznego oprogramowania (poczta elektroniczna, bramka SMS, komunikator) a w drugim można korzystać poza regułami BPQL zewnętrznego silnika regułowego jak na przykład Drools.

Nazwa atrybutu	Opis atrybutu
id	Identyfikator mapowania.
Nazwa	Nazwa atrybutu aplikacji, którego dotyczy mapowanie.
Wartość	Reguła języka BPQL reprezentująca mapowanie.

Tabela 4. Specyfikacja atrybutów mapowań parametrów Aplikacji

Rysunek 9. Formatka mapowania wartości parametru aplikacji

System docuRob®WorkFlow wspiera trzy protokoły wywołania:

• Java – aplikacja implementuje interfejs aplikacji zewnętrznej zdefiniowany w systemie docuRob®WorkFlow i jest implementowana jako klasa języka Java. Protokół ten działa tylko w trybie synchronicznym. Pole usługa specyfikuje pełną lokalizację klasy (pakiety i nazwa klasy). Ten protokół służy również do wywoływania konektora usług sieciowych REST (Representational State Transfer).

• URL – aplikacja jest wywoływana za pomocą adresu URL dostępnego poprzez protokół HTTP. Protokół ten charakteryzuje przede wszystkim wywołanie czynności manualnej i działa tylko w trybie synchronicznym. Pole Usługa specyfikuje konkretny adres wywołania.

• WebService – aplikacja jest usługą sieciową udostępniająca jedną lub więcej operacji. Specyfikacja aplikacji może być pobrana z serwera UDDI (Universal Description, Discovery and Integration lub bezpośrednio z pliku WSDL. Po odczytaniu specyfikacji danej usługi automatycznie wczytywana jest lista parametrów wejściowych i wyjściowych. Protokół ten charakteryzuje wywołanie czynności automatycznej i działa w trybie asynchronicznym. Pole Nazwa określa nazwę usługi a pole Usługa specyfikuje nazwę wywoływanej operacji w tej usłudze. Specyfikacja usługi może wykorzystywać protokół SOAP lub REST.

  

Rysunek 10. . Przykładowa definicja parametrów Aplikacji dla wywołania usługi SOAP

W celu określenia lokalizacji WSDL’a należy wybrać przycisk oznaczony ikonką zielonego plusa .

Rysunek 11. Fragment okna definicji parametrów Aplikacji dla protokołu Web Service

W wyświetlonym interfejsie należy podać adres URL usługi sieciowej czyli lokalizację pliku WSDL.

Rysunek 12. . Interfejs wskazania lokalizacji WSDL

Po zatwierdzeniu następuje odczytanie specyfikacji zawartej w WSDL.

Następnie w polu Nazwa należy wybrać dostępną pozycję z nazwą serwisu.

Rysunek 13. Wskazanie serwisu w polu Nazwa

Po wskazaniu serwisu w polu Nazwa automatycznie wypełnione zostaną pola: Usługa, Endpoint oraz wczytywana zostanie lista parametrów wejściowych i wyjściowych w tabeli Parametry.

Rysunek 14. Przykładowa definicja parametrów Aplikacji po wskazaniu serwisu

W polu Usługa można wskazać jedną spośród dostępnych usług dla serwisu

Rysunek 15. Wybieranie usługi

Po każdym wybraniu usługi wczytywana jest lista parametrów wejściowych i wyjściowych. Należy wyspecyfikować parametry wejściowe i wyjściowe usługi poprzez uzupełnienie kolumny Wartość w tabeli Parametry.

Rysunek 16. Przykładowa definicja parametrów usługi

• Konektor usług sieciowych REST - Usługę sieciową REST można wywołać przy wykorzystaniu predefiniowanej klasy Java. Wywołujemy ją w protokole JAVA, specyfikując nazwę i usługę podając pełną nazwę klasy:

  pl.rodan.ooworkflow.environment.activity.CallRestService

  Przykład wywołania usługi REST systemu eDoręczenia pokazuje Rysunek 17.

  Należy dodatkowo wyspecyfikować atrybuty wejściowe:

  • method - do określenia metody wywołania ['GET', 'POST', 'PUT', 'DELETE']

  • URL - do określenia adresu wywołania wraz z parametrami

  • requestBody - do określenia zawartości wywołania, należy zachować format JSON

  • oraz Rodzaj atrybut wyjściowy:

  • responseBody - do wskazania parametru, w którym zostanie umieszczona odpowiedź wywołania usługi w formacie JSON.

    

Rysunek 17. Przykładowa definicja parametrów konektora dla wywołania usługi REST

Rysunek 18 i Rysunek 19 pokazują odpowiednio graf historii wykonania procesu zawierającego odwołanie (czynność nr 13) do usługi REST i stan zmiennych globalnych w kontenerze procesu.

Rysunek 18. Graf historii wykonania odwołania do usługi REST

Rysunek 19. Stan zmiennych globalnych procesu po wykonaniu usługi

Przypisanie wykonawcy

Przypisanie wykonawcy (ang. workflow participant) jest obowiązkowe dla zadań typu „Użytkownik” i „Ręczna”. Opcjonalnie również dla „Wysłania” i „Odbioru” komunikatu. Wyrażenia BPQL przypisuje Wykonawcę lub wielu Wykonawców do zadania jeżeli zostanie zaznaczona opcja Auto. W przypadku ręcznego wyboru osoba decydująca o wykonaniu zadania wybiera Wykonawcę z listy. Interfejs definicji Wykonawcy (ang. Work Participant Assignment) przedstawia Rysunek 20.

Rysunek 20. Definicja Wykonawcy dla zadania.

Zaznaczenie opcji Jeden oznacza, że system pozwoli tylko jednemu z potencjalnych, to jest wybranych przez wyrażenie BPQL, wykonawców na wykonanie zadania jednocześnie, po podjęciu zadania z listy zadań przez jednego z wykonawców likwidując wpis zadania z list zadań pozostałych wybranych użytkowników. Wybranie opcji Wszyscy powoduje utworzenie tylu instancji zadania ilu użytkowników zostało wybranych przez wyrażenie BPQL.

Zadanie Ad hoc

Zadanie Ad hoc są wykonywane zgodnie z następującymi regułami:

1. Instancja zadania Ad hoc jest tworzona w momencie otrzymania znacznika jeżeli jest ono powiązane z grafem otaczającego go procesu/podprocesu poprzez Przepływ(y) wchodzący(e). W innym przypadku instancjacja zadania Ad hoc następuje w momencie instancjacji otaczającego go procesu/podprocesu.
2. Instancjacja wszystkich czynności, które nie mają Przepływów wchodzących, następuje w momencie instancjacji zawierającego je podprocesu. Dla zadań typu „Użytkownik” lub „Ręczne” jest tworzona lista wykonawców zgodnie z odpowiednim wyrażeniem BPQL. Każdy z wyznaczonych Użytkowników może wielokrotnie wykonywać przydzielone zadania.
3. Jeżeli zadanie Ad hoc jest wieloinstancyjne to każdy z Użytkowników, który otrzymuje informację o zadaniu do swojej Listy zadań może je wykonywać dowolną liczbę razy. Wskaźniki pętla sekwencyjna lub równoległa decydują o synchronizacji wykonania instancji, przy czym w pierwszym przypadku instancje będą udostępniane sekwencyjnie a w drugim współbieżnie.
4. Wykonanie każdej instancja zadania „Użytkownik” może zostać przerwane i wznowione, odpowiednio przez usługę „Zapisz” lub „Zapisz i Zamknij”. W tym drugim przypadku znacznik zostanie wysłany po odpowiednim przejściu wychodzącym jeżeli takie istnieje.
5. Zakończenie wykonania zadania Ad hoc następuje gdy wszystkie jego instancje zostaną zakończone.

Podproces

Podproces nazywany również czynnością złożoną jest samodzielnym elementem dostępnym w ramach biblioteki definicji procesów, który może być wykorzystany zarówno jako element funkcjonalny obejmującego go procesu i/lub jako samodzielny proces najwyższego poziomu wywoływany przez zewnętrzny system informatyczny. Podproces występuje w grafie obejmującego go procesu jako symbol zadania oznaczony w dolnej linii opisu znakiem +

Klasycznym przykładem takiej architektury oprogramowania może być proces rozpoznawania treści dokumentu (ang. Optical Character Recognition (OCR)), który jest wykorzystywany do automatyzacji rozpoznawania różnych dokumentów, na przykład faktur lub aktów notarialnych, zarządzanych zazwyczaj różnymi procesami obiegu dokumentów. Definicja podprocesu obejmuje jego dane, to jest parametry wejściowe i wyjściowe oraz zmienne globalne i lokalne. Enkapsulacja definicji procesu/podprocesu powoduje pełną izolację ich Kontenerów danych.

Ze względu na usytuowanie definicji podprocesu w grafie obejmującego go procesu, który poprzez warunki przepływów tworzy kontekst jego instancjacji, może on zawierać tylko jedno zdarzenie startowe oznaczone jako „Początek”. Podprocesy mogą być zagnieżdżane na wielu poziomach. Współpraca zagnieżdżonych procesów jest możliwa dzięki wymianie parametrów.

Rysunek 21 prezentując pola definicji wywołania procesu udostępnionego w bibliotece dostępnych procesów narzędzia projektowania, który ma być udostępniony jako podproces w ramach definiowanego procesu wyższego poziomu. Powiązanie pomiędzy definicją integrowanego procesu a wołającym go procesem/podprocesem odbywa się przez nazwę biblioteczną tego pierwszego.

Jeżeli wołany proces ma zdefiniowane parametry wejściowe i/lub wyjściowe to automatycznie zostaną one umieszczone w polu parametrów w zakładce proces definicji wołającego procesu. Dla każdego z umieszczonych na liście parametrów należy dodać wyrażenie BPQL używającego zmiennych globalnych. Utworzony w ten sposób zostanie mechanizm przekazywania wartości parametrów pomiędzy procesem wyższego poziomu a wołanym przez niego podprocesem.

Rysunek 21. Wywołanie dostępnego procesu obsługującego dany podproces

Aby zdefiniować nowy parametr wejściowy lub wyjściowy procesu w narzędziu projektowania procesów, należy:

• przejść na dany proces znajdujący się w panelu listy definicji procesów
• przejść na węzeł Kontener, w prawym panelu zostanie wyświetlona lista aktualnie zdefiniowanych atrybutów kontenera procesu
• Wybrać pozycję menu Kontener->Dodaj
• Wprowadzić dane o parametrze, w tym:
  • Nazwa – podać unikalną nazwę. Zasadniczo jako nazwę podaje się ciąg znaków alfanumerycznych rozpoczynających się małą literą. Każdy nowy wyraz jest dołączany do istniejących i zaczyna się od dużej litery. W nazwie atrybutu nie zaleca się stosować polskich znaków diakrytycznych.
  • Rodzaj – dla parametru wejściowego należy wybrać wartość in. Dla parametru wyjściowego – wartość out. W przypadku gdy dany parametr wejściowy jest wykorzystany także jako parametr wyjściowy (rezultat), należy ustawić Rodzaj na in/out.
  • Tylko do odczytu – wskazuje, że dany parametr będzie wykorzystywany tylko do odczytywania danych a w momencie próby zapisu wystąpi błąd. W przypadku parametru wejściowego parametr ten jest automatycznie ustawiany na Tylko do odczytu. W przypadku parametru wyjściowego parametr ten powinien pozostać odznaczony.
  • Typ -typ atrybutu, należy wybrać właściwy typ z listy dostępnych typów.
  • Wielowartościowy – jeżeli parametr przyjmuje wiele wartości, to należy zaznaczyć to pole,
  • Obowiązkowy – jeżeli zawsze jest wymagana wartość atrybutu, to należy zaznaczyć to pole. Z praktycznego punktu widzenia opcja ta ma sens jedynie przy parametrach wejściowych bo najczęściej wartość parametru wyjściowego nie jest znana przy rozpoczęciu procesu.

Podproces Ad hoc

Podproces Ad hoc ma zastosowanie dla przypadków w których podstawowym wymaganiem jest utworzenie elastycznego środowiska wsparcia pracy grupowej . Przykładem może być zbiorowy projekt tworzenia raportu badawczego lub oprogramowania w którym mamy dobrze określone etapy pracy wykonywane przez uczestników zespołu. W takich przypadkach semantyka oparta o przesyłanie znaczników może mieć tylko częściowe zastosowanie. Podproces Ad hoc może ale nie musi być powiązany z grafem obejmującego go procesu.

Definicja procesu/podprocesu Ad hoc może zawierać takie elementy przepływu jak czynności, przepływy, bramki, i pośrednie zdarzenia. Przesyłanie znaczników zachodzi pomiędzy czynnościami i pośrednimi zdarzeniami powiązanymi w ramach struktury przepływów.

Przyjęto następujące reguły sterowania wykonaniem podprocesu Ad hoc:

1. Instancja podprocesu Ad hoc jest tworzona w momencie otrzymania znacznika jeżeli jest on powiązany z grafem otaczającego go procesu/podprocesu poprzez Przepływ(y) wchodzący(e). W innym przypadku instancjacja podprocesu Ad hoc następuje w momencie instancjacji otaczającego go procesu/podprocesu.
2. Instancjacja wszystkich czynności, które nie mają Przepływów wchodzących, następuje w momencie instancjacji zawierającego je podprocesu. Dla zadań typu Użytkownik lub Manual jest tworzona lista wykonawców zgodnie z odpowiednim wyrażeniem BPQL. Każdy z wyznaczonych użytkowników może wielokrotnie wykonywać przydzielone zadania.
3. Jeżeli zadania Ad hoc są wieloinstancyjne to każdy z użytkowników otrzymuje informację o zadaniu do swojej listy zadań. znaczniki pętli sekwencyjna lub równoległa decydują o synchronizacji wykonania instancji, przy czym w pierwszym przypadku instancje będą udostępniane sekwencyjnie a w drugim współbieżnie. W przypadku zadań pojedynczych pobranie zadania z listy zadań powoduje wykasowanie go z pozostałych list.
4. Wykonanie każdej instancja typu Użytkownik może zostać przerwane i wznowione, odpowiednio przez Usługę Zapisz lub Zapisz i Zamknij. W tym drugim przypadku jej znacznik zostanie wysłany po odpowiednim przejściu wychodzącym jeżeli takie istnieje.
5. Czynności otrzymujące znacznik przez przepływ wchodzący są wykonywane a w przypadku zadań typu Użytkownik lub Ręczne. Przypisanie wykonawcy odbywa się zgodnie w wynikiem wyrażenia BPQL. Po zakończeniu wykonania takiej czynności znacznik jest wysyłane po przepływie wychodzącym lub jeżeli go nie ma to jest konsumowany.
6. Zakończenie wykonania podprocesu Ad hoc następuje gdy w jego czynnościach nie ma już żadnego znacznika.

Podproces sterowany zdarzeniem

Podprocesy sterowane zdarzeniem nie są powiązane ze strukturą przepływów obejmującego je procesu. Oznacza to, że taki podproces stanowi osobny graf umieszczony w ramach modelu obejmującego go procesu/podprocesu. Graf podprocesu sterowanego zdarzeniem jest otoczony nazwaną ramką z wykropkowanej linii i nie może być źródłem and celem żadnego Przepływu. W ramach modelu takiego podprocesu mogą wystąpić wszystkie obiekty przepływu przewidziane w BPMN 2.02 natomiast nie może on mieć zdarzeń krawędziowych.

Podproces sterowany zdarzeniem może zawierać tylko jedno początkowe zdarzenie przechwytujące, które nasłuchuje na odpowiadający mu zdarzenie rzucające od momentu instancjacji otaczającego procesu.

Zależnie od użytego w modelu symbolu zdarzenia mogą przerywać lub nie wykonanie instancji procesu/podprocesu otaczającego inicjowany przez nie podproces. Instancjacja podprocesu może mieć miejsce tylko gdy otaczający go proces/podproces jest aktywny przy czym może ona wystąpić wiele razy powodując utworzenie wielu współbieżnych instancji.

Instancja podprocesu sterowanego zdarzeniem jest w przypadku przechwytujących zdarzeń nieprzerywających tworzona dla każdego z równolegle zachodzących zdarzeń. Ze względu na ich umiejscowienie wewnątrz obszaru wywołującego je procesu/podprocesu podprocesy sterowane zdarzeniem mają dostęp do kontekstu obejmującego je procesu/podprocesu. Wykonanie obejmującego procesu/podprocesu odbywa się współbieżnie do uruchomionych instancji podprocesów sterowanych zadaniami.

Początkowe zdarzenia przerywające zawsze powodują przetwarzanie tylko jednej instancji podprocesu sterowanego zdarzeniem. Kontekst obejmującego przerywanego procesu/podprocesu jest dostępny dla oprogramowania obsługującego zdarzenie (ang. Event handler) w fazie zakańczania aby umożliwić dokończenie obsługi.

Podproces sterowany zdarzeniem może opcjonalnie powtórzyć (ang. re-trigger) zdarzenie, które go uruchomiło aby kontynuować jego przetwarzania na zewnątrz otaczającego go procesu/podprocesu poprzez jego odpowiednie zdarzenie krawędziowe.

Bramki

Czynność sterująca (ang. control activity, routing activity) jest elementem definicji przepływu sterowania wykorzystywanego do wykonania czynności równolegle, alternatywnie bądź opcjonalnie. Modelując proces mamy do dyspozycji dwie grupy bramek; a mianowicie bramki rozpływu generujące jeden lub więcej znaczników i sterujące ich dalszym przepływem i bramki łączenia otrzymujące jeden lub więcej znaczników i generujące jeden znacznik.

Bramki rozpływu

Symbol	Nazwa	Opis
	Bramka sterowana zdarzeniami	Konfiguracja bramki, w odróżnienia od pozostałych typów, zależy nie od wartości zdefiniowanych w niej warunków rozpływu lecz od konfiguracji zdarzeń umieszczonych na docelowych końcach jej przepływów wychodzących..
	Bramka rozpływu AND (AND Split)	Bramka tworzy wiele równoległych ścieżek generując znaczniki zgodnie z liczbą jej przepływów wychodzących bez sprawdzania jakichkolwiek wyrażeń warunkowych.
	Bramka rozpływu XOR (XOR Split)	Bramka tworzy jedną z alternatywnych ścieżek w ramach konfiguracji jej przepływów wychodzących. Wybrany przepływ wychodzący musi spełniać przypisane do niego wyrażanie warunkowe. Jeżeli żadne z jej przepływów wychodzących nie spełnia powyższego wymagania to znacznik jest przesyłany domniemanym przepływem wychodzącym jeżeli taki został uwzględniony w konfiguracji Bramki.
	Bramka rozpływu OR (OR Split)	Bramka tworzy wiele z alternatywnych ścieżek w ramach konfiguracji jej przepływów wychodzących. Wybrany przepływ wychodzący musi spełniać przypisane do niego wyrażanie warunkowe. Jeżeli żadne z jej przepływów wychodzących nie spełnia powyższego wymagania to znacznik jest przesyłany domniemanym przepływem wychodzącym jeżeli taki został utworzony.
	Złożona bramka rozpływu (Complex Split)	Bramka generuje przynajmniej jeden znacznik dla wybranego przepływu wychodzącego bramki a co najwyżej po jednym znaczniku dla każdego przepływu wychodzącego. Zarówno wybór właściwych przepływów wychodzących jak i generowanie znaczników wykonuje wyrażenie BPQL utworzone przez projektanta procesu.

Tabela 5. Typy operatorów rozpływu

Bramka służy do rozdzielenia sterowania. W terminach znaczników, Bramka konsumuje jeden znacznik a generuje jeden lub więcej znaczników w zależności od typu operatora. Reprezentacja graficzną operatora jest romb pogrubiony z lewej strony. Opis działania Bramek rozpływu zawiera Tabela 5.

Bramki łączenia

Bramka łączenia służy do złączenia sterowania. W terminach znaczników, operator ten konsumuje jeden lub więcej znaczników, w zależności od typu operatora a generuje jeden znacznik. Są trzy typy Bramek: ANDJoin, ORJoin i XORJoin. Reprezentacja graficzną operatora jest romb pogrubiony z prawej strony. Opis działania bramek łączenia opisuje Tabela 6.

Symbol	Nazwa	Opis
	Bramka łączenia AND (AND Join)	Znaczniki przybywające przez przepływy wchodzące do równoległej bramki łączenia (AND) są zamieniane na jeden znacznik wysyłany jej przepływem wychodzącym dopiero po otrzymania ich wszystkich.
	Bramka łączenia XOR (XOR Join)	Znaczniki spełniające warunki przejścia przybywające przez przepływy wchodzące do ekskluzywnej bramki łączenia (XOR) są zamieniane na jeden znacznik wysyłany jej przepływem wychodzącym po otrzymaniu przynajmniej jednego z wchodzących znaczników.
	Bramka łączenia OR (OR Join)	Znaczniki spełniające warunki przejścia przybywające przez przepływy wchodzące do bramki łączenia (OR) są zamieniane na jeden znacznik wysyłany jej przepływem wychodzącym po otrzymaniu wszystkich.

Tabela 6. Typy operatorów łączenia

Przepływy

Przepływ (ang. flow) jest łącznikiem pomiędzy dwoma czynnościami wskazując kolejność ich wykonywania. Przejście może posiadać warunek. Wyrażenie warunkowe jest definiowane jako reguła BPQL. Aktywność przepływu jest symbolicznie interpretowana jako przesłanie znacznika (ang. token) pomiędzy czynnościami. Warunkiem aktywności przepływu, który ma wyrażenia warunkowe jest zwracanie prze nie wartości „prawda” (ang. true). Typy Przepływów prezentuje Tabela 7.

Symbol	Nazwa	Opis
	Przepływ (ang. Sequence flow)	Przepływ może ale nie musi zawierać wyrażenia warunkowego sterującego przekazaniem znacznika pomiędzy czynnościami
	Przepływ wychodzący z zadania z warunkiem	Przepływ wychodzący z zadania jest oznaczany rombem jeżeli zawiera definicję warunku.
	Domniemany przepływ (ang. default flow(	Domniemany przepływ przekazuje znacznik pomiędzy czynnościami jeżeli wyrażenia warunkowe wszystkich Przejść wychodzących zadania lub bramki mają wartość „fałsz” (ang. false).

Tabela 7. Typy przepływów

Panel definiowania metadanych Przepływu (Rysunek 22) obejmuje wszystkie elementy konieczne do jego wykonania. Źródłowa i docelowa czynność są identyfikowane opcjonalnie nazwą i automatycznie numerem czynności w grafie procesu/podprocesu.

Wyrażenie warunkowe sterujące symbolicznie przekazaniem znacznika jest tworzone w BPQL i jest wspomagane edytorem wyrażeń języka zgodnie z ogólnymi zasadami przyjętymi w systemie. Warunek jest ignorowany jeżeli przepływ został oznaczony polem Domyślny.

Przepływ domyślny oznaczony odpowiednim polem wyboru jest wykonywany w przypadku gdy wszystkie inne przejścia nie mogą zostać uruchomione ze względu na przyjęte w nich wyrażenia warunkowe.

Warunki przejść są wyrażeniami logicznymi określającymi, czy dane przejście zostanie wykonane czy nie. Dany warunek jest reprezentowany przez regułę BPQL i może zawierać dowolne elementy języka, które ostatecznie wartościują się do typu Boolean. W praktyce warunek przepływu sterowania jest definiowany w oparciu o zmienne globalne procesu oraz funkcje BPQL, które udostępniają dane obiektów i formularzy przetwarzanych w ramach procesu.

Aby zdefiniować warunek, należy będąc na zakładce Model procesu zaznaczyć właściwe przejście i kliknąć dwukrotnie lewym klawiszem myszki. Na ekranie pojawia się okno dialogowe do wprowadzania danych o przejściu. Dostarcza ono następującej informacji:

• Od czynności – numer i nazwa czynności początkowej, od której jest zdefiniowane przejście. Wartość tylko do odczytu.
• Do czynności - numer i nazwa czynności końcowej, do której jest zdefiniowane przejście. Wartość tylko do odczytu.
• Nazwa – nazwa przejścia. Nazwa ta pojawia się w zakładce Model procesu.
• Opis – dodatkowa informacja o przejściu wypełniana w celach dokumentacyjnych.
• Warunek – wyrażenie BPQL.

Przy definiowaniu warunku przejścia możliwe jest wstawianie operatorów logicznych: AND, OR, NOT przy pomocy przycisków znajdujących się lewej dolnej części okna. W celu wybrania zmiennej globalnej lub funkcji wbudowanej BPQL, należy kliknąć na przycisk „Wstaw”. Na ekranie pojawia się standardowe okno wprowadzania informacji o strukturze organizacyjnej, funkcjach wbudowanych i zmiennych globalnych. W zakładce Struktura org. można wybrać cztery kategorie danych:

• Funkcja – na ekranie pojawia się lista funkcji BPQL, które można wykorzystać do zdefiniowania warunku. Wybór funkcji następuje po dwukrotnym kliknięciu na jej nazwę lub zaznaczeniu funkcji i kliknięciu na klawisz Wybierz
• Stanowisko – podaje listę stanowisk zdefiniowanych w systemie. Lista ta może się różnic w zależności od słowników danego klienta.
• Grupa – umożliwia wybranie grupy funkcyjnej lub komórki organizacyjnej zdefiniowanej w systemie docuRob®WorkFlow lub zsynchronizowanej z właściwym systemem zarządzania pracownikami.
• Pracownik- lista pracowników zatrudnionych w danej grupie lub komórce organizacyjnej wybranej z rozwijanej listy grup i komórek.

Wybór zmiennej globalnej wykonuje się na drugiej zakładce. Po jej wybraniu wyświetlana jest lista dostępnych atrybutów wraz z informacją o typie i rodzaju zmiennej. Podwójne kliknięcie na daną zmienną powoduje jej wybranie.

Rysunek 22. Metadane obiektu Przepływ

Inne symbole graficzne

Wykorzystanie innych symboli graficznych w ramach grafu procesu omawia Tabela 8.

Symbol	Nazwa	Opis
	Rola (ang. Swimlane)	Intencją specyfikacji BPMN 2.02 jest wykorzystanie obszaru Rola do grupowania zadań wykonywanych przez Użytkowników procesu występujących w danej roli. Na przykład rola Technolog. Taka metoda modelowania grafu procesu w poważnym stopniu utrudnia zachowanie czytelności modelu. Dlatego wprowadziliśmy alternatywne oznaczanie zadań w ramach Roli poprzez odpowiednie przypisywanie kolorów wypełnień ich symboli.
	Obiekt danych (ang. data object)	Wprowadzenie Obiektów danych oraz ich powiązań z zadaniami ma znaczenie dla przekazania informacji projektowych na poziomie pojęciowego modelu procesu tworzonego w fazie analizy wymagań. Ze względu na obsługę danych w oparciu kontener danych procesu/podprocesu symbole Obiektów danych oraz ich powiązań nie są interpretowane na poziomie wykonania procesu.
	Powiązanie (ang. Association)	Symbol Powiązania jest wykorzystywany jako oznaczenia związku pomiędzy krawędziowym zdarzeniem typu „Kompensacja” a czynnością kompensującą”.
	Ramka (ang. Frame)	Ramka oznacza zakres grafu podprocesu sterowanego zdarzeniem, którego model umieszczono razem z otaczającym go procesem/podprocesem.

Tabela 8. Inne symbole graficzne

Przykład

Przedstawiony przykład jest celowo neutralny z punku widzenia aplikacyjnego i wszystkie zawarte w nim czynności są oznaczone dużymi literami alfabetu. Celem przykładu jest ilustracja alternatywnych metod modelowania procesu, to jest sterowania poprzez definicję rozpływu i łączenia sterowania przez operatory logiczne udostępniane w zakładce „Przepływ” panelu definicji czynności (Rysunek 23) lub poprzez definicję bramek rozpływu i łączenia (Rysunek 24)

Rysunek 23. Definicja procesu z przepływami definiowanymi w metadanych czynności

Przedstawione modele alternatywnych procesów są wygenerowane przez narzędzie projektowania procesów platformy docuRob®WorkFlow. Celowo pominięto możliwość oznaczanie ról wykonawców w zadaniach typu „Użytkownik”. Rysunek 25 do Rysunek 28 ilustrują historię wykonania czterech różnych przebiegów procesów

Rysunek 24. Definicja procesu z przepływami przez Bramki

Wykonane przebiegi czterech par instancji procesów powołanych odpowiednio na podstawie alternatywnych modeli różnią się między sobą wartościami logicznymi (typ Boolean) zmiennych globalnych sterujących przepływami w ramach obu instancji. Różnice w ustawieniu wartości zmiennych logicznych w wariantach wykonania modeli 1-4 pokazuje Tabela 9. Dla kolejnych wariantów przebiegów pokazano jedynie wiersze różniące w się w stosunku do wariantu przebiegu 1.

Przebieg 1 (Rysunek 25) został wykonany po wprowadzeniu zmiennych globalnych o wartościach „true” jako parametrów wejściowych powoływanych instancji. Obie oczekiwane równoległe ścieżki instancji definicji (bramka AND) zostały wykonane.

Różnica pomiędzy wariantami 1 i 2 wykonania par procesów polega na przypisaniu wartości false zmiennej logicznej $zn11 sterującą przepływem pomiędzy czynnościami A i B (Rysunek 23) lub w przypadku modelu opartego o bramki pomiędzy bramką Split OR a czynnością A (Rysunek 24). Zablokowanie tego przejścia spowodowała wykonania tylko jednej ścieżki procesu w wariancie przebiegu 2.

Przebieg	Czynność	In	Out	zn11	zn12	zn31	zn32	zn21	zn22	zn23
1	Start	XOR	AND	T	T	T	T	T	T	T
	A	OR	OR	T	T	T	T	T	T	T
	C	XOR	OR	T	T	T	T	T	T	T
	B	XOR	OR	T	T	T	T	T	T	T
	D	XOR	OR	T	T	T	T	T	T	T
	E	XOR	OR	T	T	T	T	T	T	T
	F	XOR	OR	T	T	T	T	T	T	T
2	A	OR	OR	F	T	T	T	T	T	T
3	A	OR	OR	T	F	T	T	T	T	T
	C	XOR	OR	T	T	T	F	T	T	T
4	E	XOR	OR	T	T	T	T	T	F	T

Tabela 9. Konfiguracje warunków przepływów w przebiegach 1-4.

Wariant przebiegu 3 przy ustawieniu zmiennych logicznych $zn12 i $zn32 na wartość false spowodowała zablokowanie rozpływu AND w obu modelach i odpowiednio zakończenie obu równoległych ścieżek instancji procesów po wykonaniu instancji czynności (zadań) A i C.

Wariant przebiegu 4 przy ustawieniu wartości zmiennej logicznej $zn22 na false pominie wykonanie czynności E.

Celem przykładu jest między innymi pokazanie ekwiwalencji funkcjonalnej instancji procesów opartych o alternatywne definicje modeli polegającej na uzyskaniu takich samych ścieżek wykonania zadań.

Wybór grafu opartego o czynności sterujące (bramki) jest semantycznie bogatszą alternatywą i wydaje się bardziej przyjazny dla użytkowników odpowiedzialnych za automatyzację procedur działalności w oparciu o architekturę procesową (przedstawiciele biznesu).

W przypadku zastosowania wewnętrznej definicji przepływów możemy oczekiwać zwiększonej wydajności przetwarzania instancji procesów (mniejszego obciążenia konfiguracji serwerowej) ze względu na uniknięcie obciążenia wynikającego z uruchamianiu większej liczby instancji czynności sterujących. Takie podejście jest niewątpliwie lepsze w przypadku procesów zawierających większość czynności automatycznych.

Rysunek 25. Przebieg 1

Rysunek 26. Przebieg 2

W ramach instancji procesów drugiego przebiegu wykonanego po przyjęciu warunku $zn11*=false* została wykonana ścieżka <Start, C, B, D, E, F>. Druga równoległa ścieżka została dla obu instancji przerwana na etapie przepływu wyjściowego zadania A. Łatwo zauważyć, że przerwania równoległej ścieżki procesu po wykonaniu instancji czynności A spowoduje jednokrotne wykonanie zadań <B, D, E, F>.

Rysunek 27. Przebieg 3

W trzecim przebiegu przyjęto wartości false dla zmiennych logicznych $zn12 i $zn32. Taka konfiguracja warunków przepływu spowodowała przerwania obu ścieżek po wykonaniu zadań A i C. W przypadku modelowania warunku wyjściowego zadania A wykorzystano przepływ domniemany.

Rysunek 28. Przebieg 4

W czwartym przebiegu przyjęto wartość zmiennej logicznej zn22=true co spowodowało niezgodność z warunkiem wejścia do zadania E. W instancjach obu modeli nie wykonana tej czynności.